Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fixes for improved RPL support #388

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Fixes for improved RPL support #388

wants to merge 2 commits into from

Conversation

Crementif
Copy link
Contributor

@Crementif Crementif commented Jul 6, 2024 •
edited
Loading

@Exzap agreed upon me reviving his #325 PR with the suggested changes.

To rephrase his PR a bit, this is meant to address two problems that prevents RPLs from being usable:

  • LR isn't correctly restored in __rpl_start leading to an endless loop or crash. This PR adds the assembly that was missing.
  • The current behavior is that RPLs use wutmalloc, which assumes that MEMGetSizeForMBlockExpHeap can be used to determine the size when reallocating memory. This adds a separate wutmalloc implementation that only RPLs will use, which co-allocates a header alongside memory so that RPLs can now reallocate memory.

I've tested the changes with RPX files that both use the custom heap and override preinit_user to use the wutmalloc implementation. This PR allows Aroma plugins/modules to continue to have access to the regular malloc implementation, while RPLs are now fully functional. After that, follow up PRs can be made to address some of the minor issues that are left to complete the RPL support in wut.

Crementif added 2 commits July 5, 2024 22:40
@Crementif
crt0: Restore LR in __rpl_start
35bcf9d
@Crementif
Add special wutmalloc version of
3aaa683 
Taken from devkitPro@92d343c but separated into its own header to ensure a fast path for wutmalloc users that don't need to co-live alongside non-SRBK heap implementations, like RPLs have to.
@Exzap Exzap mentioned this pull request Jul 6, 2024
Closed
@rapito
Copy link

rapito commented Feb 2, 2025 •
edited
Loading

Hi! Just bumping this PR, seems like this would allow for the glsl compiler to be a thing. Trying to find a way to compile some shaders from macos and it's been an adventure.

Wondering what might be needed for this PR to be merged?

@Crementif
Copy link
Contributor Author

Crementif commented Feb 3, 2025 •
edited
Loading

Trying to find a way to compile some shaders from macos and it's been an adventure.

For the time being you could use Docker/VM and use the linux binary from the latest CafeGLSL release. Unfortunately it doesn't really solve the ability to dynamically compile shaders, which is what things like retroarch would need. Merging this PR shouldn't have any downsides, but I think that since it's not the full rework that would be required for proper RPL support it just hasn't happened yet. But it would be interesting to hear something official!

@rapito
Copy link

rapito commented Feb 3, 2025

Trying to find a way to compile some shaders from macos and it's been an adventure.

For the time being you could use Docker/VM and use the linux binary from the latest CafeGLSL release. Unfortunately it doesn't really solve the ability to dynamically compile shaders, which is what things like retroarch would need. Merging this PR shouldn't have any downsides, but I think that since it's not the full rework that would be required for proper RPL support it just hasn't happened yet. But it would be interesting to hear something official!

Thanks, I completely disregarded the Docker part. Will do.
Been banging my head around just to get some textures into some 3d models.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@Crementif @rapito